Agiilsed arendusmudelid - SCRUM

Mis on agiilsed arendusmudelid?

Agiilne arendusmudel on nö vihmavari mõiste. See koondab enda alla paindlikud mudelid, mis eelistavad iteratiivset ja kohandatavat tarkvaraarendust, klientide kaasamist ja meeskonnatööd. Nende meetodite eesmärk on toota töötavat tarkvara väikestes inkrementides, kaasates tagasisidet ning tehes muudatusi vastavalt vajadustele.

Mis on Scrum?

Scrum on agiilses tarkvaraarenduses kasutatav raamistik, mida iseloomustavad väikesed iseorganiseeruvad meeskonnad, kes töötavad lühikestes iteratiivsetes tsüklites, mida nimetatakse sprintideks. Struktuur rõhutab meeskonnatööd, kohanemisvõimet ja järkjärgulist keskendumist funktsionaalse tarkvara tootmisele.

Scrum näeb ette, et meeskonnad jagavad töö eesmärkideks, mis tuleb saavutada ajaliselt piiratud tsüklite ehk sprintide raames. Tsüklid kestavad tavaliselt kaks nädalat ja mitte kauem kui üks kuu. Sprintide korduseid tehakse olenevalt projekti pikkusest ning vajadusel nii palju kuni on sobiv toode valmis. Meeskond hindab edusamme lühikeste kuni 15-minutilistel koosolekutel, mida nimetatakse igapäevasteks scrumideks.

Sprindi lõpus peab meeskond veel kaks koosolekut: üks sprindi ülevaate, et demonstreerida tööd klientidele ja küsida tagasisidet, ning teine meeskonna sisemine sprindile tagasivaatav.

Scrum-meeskonna eest vastutavat isikut nimetatakse tavaliselt scrum masteriks.

Scrum etapid

Scrumi elutsüklis on 5 etappi: Algatamine, Planeerimine, Teostamine, Ülevaatamine ja Tagasiside, ning Avalikustamine. Nendest ei kuulu sprindi juurde algatamine ning avalikustamine. Ehk siis need kaks etappi on vastavalt projekti alguses ja lõpus.

1. Algatamine

   Selle etapi jooksul loob meeskond projekti visiooni, mis sisuliselt kirjeldab tegevuskava koos peamiste eesmärkide, sihtide ja tulemustega. Samuti tuvastavad nad kõik huvigrupid, määravad meeskonnaliikmed rollidesse ja kinnistavad projekti ülesannete loetelu.

   Loetelu on koostatud tooteomaniku poolt arvestades projekti visiooni ja kliendi vajadusi. See nimekiri on järjestatud prioriteetsuse järjekorras ning sisaldab funktsioone, mis rakendatakse arenduse käigus.

2. Planeerimine

   Selles etapis tegeleb Scrumi arendusmeeskond sprindi planeerimisega. Meeskond määrab kindlaks, milliste kasutajalugudega nad tsükli jooksul töötada soovivad.

3. Teostamine

   See etapp hõlmab ülesannete ja tegevuste täitmist toote eesmärkide saavutamiseks ja projekti tulemuste lõpuleviimiseks. Olulisel kohal on igapäevased scrumid, mille abil meeskond saab ülevaate projekti staatusest ning võimalikest probleemidest.

   See Scrumi etapp võib olla nõudlik. Õige meeskonna ja õigete protsesside abil saab tagada arendusmeeskonna vahelise pideva suhtluse ja toote plaanipärase edenemise.

4. Ülevaatamine ja Tagasiside

   See etapp on agiilse scrum-protsessi oluline osa ning seda tuleks teha pärast iga sprindi lõppu. See annab võimaluse hinnata, mis oli edukas, mida saaks paremaks muuta ja kuidas edasi liikuda, kogudes klientide tagasisidet toote ja meeskonna hinnangut toimunud sprindi osas.

   See etapp sisaldab järgmisi Scrum-protsesse:

   • Sprindi ülevaade
   • Sprindi tagasivaade
   • Teostatavate tööde loetelu haldamine
   • Projekti tagasivaade (kui projekt lõpeb)

   Sprindi ülevaade võimaldab huvigruppidel ja meeskonnaliikmetel hinnata projekti edenemist. Seevastu sprindi tagasivaade annab võimaluse oma kogemuste üle järele mõelda, mõtteid jagada ja otsustada, kuidas protsessi optimeerida. Sprindi ülevaade keskendub tootele ja seda juhib tavaliselt tooteomanik. Sprindi Tagasivaade keskendub aga Scrum Masteri juhitud protsessile.

5. Avalikustamine

   See on Scrumi metoodika etappide viimane etapp ning selle eesmärk on projekti lõpptulemuste ettevalmistamine ja edastamine seotud huvigruppidele.

Scrum etappide joonis

Mis on agiilsete arendusmudelite tätsaim omadus?

Tähtsaim omadus agiilsetel mudelitel on paindlikus. Kuna tarkvaraarenduses võivad nõuded kiiresti muutuda, siis paindlikkus võimaldab kiiresti kohaneda. Kiire kohanemis võime vähendab riski, et lõpptoode ei vasta kliendi/kasutaja ootustele.

Agiilsete arendusmudelite head ja vead

mis on HEAD	mis on VEAD
Kliendile esitatakse toote tulemusi juba varakult ja järk-järgult. Kliendid näevad oma projektides iga lõpetatud sprindiga pidevat edu.	Kuna kliendi ja meeskonna vahel on vajalik pidev suhtlus, nõuab see kõigilt projektis osalejatelt palju aega ja energiat.
Risk, et klient ei jää lõpptootega rahule väheneb, kuna meeskonnal on paindlikkus reageerida kiiresti muutuvatele nõuetele.	Koostöö ja vestlus asendab suure osa dokumentatsioonist, millele tavaliselt teabe jagamiseks ja edusammude kaardistamiseks tuginetakse. Kuigi see vähendab tööd, võib see muuta raskeks uute meeskonnaliikmete projektiga kurssi viimist.
Meeskonnaliikmed on protsessi kaasatud igapäevaste sprint koosolekute kaudu ja neid julgustatakse oma ideid jagama.	Projekti üldise edenemise mõõtmine võib olla keeruline, kuna see toimub mitme iteratsiooni jooksul.
See pidev integreerimine ja testimine annab tulemuseks kvaliteetsema toote.

Veel agiilseid töövõtteid

• Käitumispõhine arendus (Behaviour driven development ehk BDD)

  See mudel julgustab kõiki projekti huvigruppe tegema koostööd süsteemi soovitud käitumise määratlemiseks enne arenduse algust. See sisaldab täpsustuste kirjutamist loomulikus keeles, mis on arusaadav nii tehnilistele kui ka mitte-tehnilistele meeskonnaliikmetele.

  BDD soodustab meeskonnatööd, luues probleemist selge ja ühise arusaama.

  • Kiiremad iteratsioonid: kiire tagasiside ja kohandused hoiavad asjad edenemas.
  • Parem koodi kvaliteet: selged nõuded vähendavad vigu ja hoolduskulusid.
  • Väiksemad riskid: kõik on samal lainel, vältides kulukaid valesamme.

• Disainipõhine arendus (Design driven development ehk DDD)

  Disainipõhine arendus asetab disaini toote loomisel esiplaanile. Selle asemel, et käsitleda disaini pelgalt esteetilise järelmõttena, rõhutab see DDD selle keskset rolli tarkvara suuna ja funktsionaalsuse dikteerimisel.

• Valdkonnapõhine arendus (Domain driven design ehk DDD)

  DDD on meetod, mis tähtsustab konkreetse probleemi valdkonna mõistmist ja modelleerimist kus tarkvarasüsteemi toimib. See rõhutab vajadust tiheda koostöö järele ekspertidega, et saada põhjalik arusaam valdkonna üksikasjadest ja keerukusest. DDD pakub põhimõtteid, mustreid ja tavasid, mis aitavad arendajatel valdkonna kontseptsioone oma tarkvaradisainis täpselt tabada ja esitada.

  Valdkonnapõhise disaini peamised eelised:

  • Soodustab tõhusat suhtlust valdkonnaekspertide, arendajate ja huvigruppide vahel, kasutades ühist keelt.
  • Aitab meeskondadel seada prioriteediks rakenduse kõige väärtuslikumad osad, et ärieesmärkide saavutamiseks.
  • Julgustab disainilahendusi, mis kohanduvad muutuvate ärivajaduste ja turutingimustega.
  • Säilitab selge erisuse valdkonnaloogika, infrastruktuuri ja kasutajaliidese vahel.
  • Toetab täpselt määratletud valdkonnaobjekte, mis muudab testimise lihtsamaks ja sihipärasemaks.

• Turvaline disainilt (Secure by Design ehk SbD)

  SbD on küberturvalisuse ja süsteemitehnika kontseptsioon, mis nõuab turvalisuse integreerimist süsteemidesse algusest peale, mitte järelmõttena. Selle asemel, et seda hiljem paikamise või väliste kontrollide abil integreerida, keskendub see turvanõuete integreerimisele arhitektuuri endasse, lisades kaitsemeetmed riist- ja tarkvara ning teenuste disaini protsessi algustamisel.

• Testipõhine arendus (Test-Driven Development ehk TDD)

  TDD on meetod tarkvaraarenduses, kus enne rakenduse või toote mis tahes funktsiooni koodi kirjutamist keskendutakse automatiseerimistestide kirjutamisele. See lähenemisviis kasutab lühikesi korduvaid arendustsükleid, et kontrollida kvaliteeti ja õigsust.

  Lihtsamalt öeldes on TDD kodeerimismeetod, mille puhul esmalt kirjutatakse test, mis ebaõnnestub, seejärel kirjutatakse arendustesti läbiv kood ja siis puhastatakse kood. Seda protsessi taaskasutatakse ühe uue funktsiooni või muudatuse jaoks. Erinevalt teistes meetodites, kus kõigepealt kirjutatakse kas kogu kood või kõik testid, ühendab TDD testid ja koodi ning kirjutab need üheks.

• Vastuvõtutesti põhine arendus (Acceptance test driven development ehk ATDD)

  ATDD on arendustehnika millel on rõhuasetus lõppkasutajal/klientidel võttes arenduse aluseks vastuvõtutestide lood. See tähendab, et see keskendub tegelikult tahetud funktsionaalsuse/käitumise pakkumisele. Vastuvõtutestid kirjutatakse kasutaja vaatenurgast ja testide lood luuakse juba enne kodeerimise algust.

  ATDD on laiendatud TDD-le, mis rõhutab arendajate, testijate ja ettevõtete koostööd ning on testikeskne lähenemine. ATDD keskendub kliendi tegelikele vajadustele.

• Pidev testidest lähtuv arendus (Continuous test driven development ehk CTDD)

  CTDD puhul on tegu tarkvaraarenduse praktikaga, mis laiendab TDD'd taustal toimuvate automaatsete testide abil (teisiti öeldes pidev testimine).

  Arendaja kirjutab testid, kuid ei pea neid käsitsi käivitama. Teste käivitab automaatselt taustal töötav pideva testimise tööriist. See tehnika võib potentsiaalselt vähendada käsitsi testide käivitamisest tulenevat ajakulu.

• Näitepõhine täpsustus (Specification by Example ehk SBE)

  SBE on meetod tarkvaratoote nõuete ja ärikesksete funktsionaal testide defineerimiseks, mis põhineb nõuete jäädvustamisel ja illustreerimisel realistlike näidete, mitte abstraktsete väidete abil. Seda rakendatakse agiilsete tarkvaraarenduse meetodite kontekstis, eriti BDD's. See lähenemisviis on eriti edukas nõuete ja funktsionaal testide haldamisel suuremahulistes projektides, millel on märkimisväärne valdkonna ja organisatsiooni keerukus.

  Näitepõhine täpsustus on tuntud ka kui näitepõhine arendus (example-driven development), käivitatavad nõuded, vastuvõtutesti põhine arendus (ATDD), agiilne vastuvõtutestimine, testipõhised nõuded (Test-Driven Requirements ehk TDR).

• Andmepõhine arendus (Data driven development ehk DDD)

  Andmepõhine arendus on strateegia, kus tarkvaratoote disain ja funktsionaalsus põhinevad andmetel. See hõlbustab toote pidevat täiustamist, tuginedes reaalsete kasutajate teadmistele, tegevus näitajatele ja ennustus mudelitele.

  Andmepõhise arendusraamistiku võti on luua süsteeme, mis kohanduvad, õpivad ja arenevad toote eluea jooksul kogutud andmete abil.

• Andmekeskne disain (Data oriented design ehk DOD)

  DOD on arvutiteaduses programmi optimeerimise meetod, mille eesmärk on protsessori vahemälu tõhus kasutamine. See lähenemisviis on sageli kasutusel videomängude arendamisel. Meetod keskendub andmete paigutusele: eraldades ja sorteerides välju vastavalt sellele millal neid vaja on, ja pöörates tähelepanu andmete teisendamisele.

Viited infole:

• Agile software development
• Scrum (project management)
• Scrum in Project Management: The Complete Guide
• What is Agile Project Management?
• What is Behavior-Driven Development (BDD)?
• Domain-Driven Design (DDD)
• What is Design-Driven Development?
• Secure by design
• What is Test Driven Development (TDD)?
• Acceptance Test Driven development (ATDD) in Software Engineering
• Continuous test-driven development
• Continuous Testing in Software Testing
• Specification by example
• Data-Driven Development
• Data-oriented design